<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//Tigris//DTD XHTML 1.0 Transitional//EN"
"http://style.tigris.org/tigris_transitional.dtd">
<html>
<head>
 <style type="text/css">
/* <![CDATA[ */ 
@import "css/readyset.css"; 
@import "css/inst.css";
/*  ]]> */
 </style>

<link rel="stylesheet" type="text/css" href="css/print.css" media="print" />
 <title>Standard terms</title>
</head>

<body>
<div class="app">
<div class="readyset">
 <h2>Glossary</h2>

 <div class="tabs">
 <table border="0" cellspacing="0" cellpadding="0"><tr>
  <td><a href="glossary.html">Project terms</a></td>
  <th>Standard terms</th>
 </tr></table>
 </div>

 <div id="processimpact">
  <strong>Process impact:</strong> This file as a
  dictionary of standard terms defined as they are used across
  projects.  Individual projects should not need to edit this file.
  Writing out the definitions of terms and acronyms here helps keep
  other documents more concise and easy to edit.  Check the <a
  href="http://readyset.tigris.org/templates/glossary-std.html">ReadySET
  glossary</a> for updates.
 </div> <!-- /processimpact -->

 <div>Jump to: 
  <a href="#general_section">General</a> |  
  <a href="#cs_section">Computer science &amp; technology</a> |
  <a href="#process_section">Process</a> |  
  <a href="#tools_section">Software development tools</a> |  
  <a href="#requirements_section">Requirements</a> | 
  <a href="#design_section">Design</a> | 
  <a href="#designgoals_section">Design goals</a> | 
  <a href="#qa_section">QA terms</a> |
  <a href="#qagoals_section">QA goals</a> |
  <a href="#additional_section">Additional terms</a> 
 </div>

 <div id="general_section"> 

 <h3>General Terms</h3>

 <dl>
  
  <dt id="chipaway">Chipping away</dt>

  <dd>The process of removing sample text from templates when that
  text does not apply to the current project.  Often some of the
  sample text will be kept or revised to fit the current project.
  Even if the sample text does not fit the current project, it
  provides a reusable example of how to phrase that type of
  description.  The term "chipping away" comes from an old joke: when
  a sculptor is asked how he carved a marble statue of a horse, he
  replies "It was easy, I just started with a big block of marble and
  chipped away everything that did not look like a horse."</dd>


  <dt id="attachedworksheet">Attached worksheet</dt>

  <dd>The idea is similar to filling in an IRS form and using
  worksheets to calculate subtotals or make specific decisions.  That
  is to say, there is a hierarchy to the templates: there are the main
  templates, and then worksheets for specific topics.  We have divided
  the information into several files so that each file is focused on
  one topic, and so that each file can be worked on by one person in a
  reasonable amount of time.</dd>

  <dt id="processimpactterm">Process impact</dt>

  <dd>The process impact box on each template explains where the
  current template fits into the software development process.  It
  usually includes a brief comment on who should create the document,
  and who would be expected to make use of it.  You can change the
  process impact box, but you should not need to.</dd>


  <dt id="checklist">Checklist</dt>

  <dd>There are two kinds of checklists:
   <ul>
    <li>Many of the templates have a section with questions that help
    you check your work in that template.  Often the sample answers to
    the questions prompt you to take some corrective action.</li>

    <li>For design and code review meetings, there are links to
    guidelines and checklists that help you identify common errors in
    those artifacts.</li>
   </ul>
  </dd>


  <dt id="stickynote">Sticky note</dt>

  <dd>The idea is similar to a post-it note attached to a document
  that tells you do "sign here" or fill in a certain part.  There are
  two types of sticky notes:
  <ul>
   <li>TODO: Instructs you on how to fill in the template.  This is
   the minimum that you need to do.  One of the main goals of ReadySET
   is to help your team <i>quickly</i> carry out basic software
   engineering activities.  The TODO sticky notes make that easy by
   making the templates more self-explanatory.</li>

   <li>TIP: Helps you think of better ways to fill in the template.
   One of the other main goals of ReadySET is to help your team make
   better decisions that can make your whole project more successful.
   The TIP sticky notes help with that.</li>
  </ul>

  After you have done what the sticky note says, you can delete the
  sticky note.  In the HTML file, they are marked with class="todo" or
  class="tip".
  </dd>


 </dl>
 </div> <!-- /general_section -->


 <div id="cs_section"> 

 <h3>Computer Science and Technology Terms</h3>

 <dl>
  
  <dt id="api">API (Application Program Interface)</dt>

  <dd>An API is a set of functions that one software component makes
  available to other software components.  That allows other programs
  to "call" this program via direct function calls, or more indirect
  communications such as <a href="#soap" class="def">SOAP</a>
  messages.</dd>

    
  <dt id="soap">SOAP (Simple Object Access Protocol)</dt>

  <dd>SOAP is the message format used by standard web services.  It
  entails sending an XML document to a server in order to invoke an
  operation on the server-side.  <a
  href="http://directory.google.com/Top/Computers/Programming/Internet/Web_Services/SOAP/?tc=1"
  >More information on SOAP</a>.</dd>

 </dl>
 </div> <!-- /cs_section -->



 <div id="process_section"> 

 <h3>Process Terms</h3>

 <dl>

  <dt id="ccb">Change Control Board (CCB)</dt>
  <dd>A group of people who review proposed changes to the project
  requirements and/or source code to accept or reject changes in each
  particular release.  Proposed changes are usually rejected if they
  introduce too much risk or would trigger additional effort (e.g.,
  the need to redo a lot of testing on new code).  A CCB is usually
  composed of managers and representatives of other stakeholders
  such as the QA group and key customers.</dd>

  <dt id="featurecomplete">Feature Complete</dt> <dd>A
  release is called "feature complete" when the development team
  agrees that no new features will be added to this release.  New
  features may still be suggested for later releases.  More
  development work needs to be done to implement all the features and
  repair defects.</dd>

  <dt id="codecomplete">Code Complete</dt>
  <dd>A release is called "code complete" when the development team
  agrees that no entirely new source code will be added to this
  release. There may still be source code changes to fix defects.
  There may still be changes to documentation and data files, and to
  the code for test cases or utilities. New code may be added in a
  future release.</dd>

  <dt id="internalreleasenumber">Internal Release Number</dt>
  <dd>An internal release number is the number that the development
  team gives each release.  Internal release numbers typically count
  up logically, i.e., they do not skip numbers. They may have many
  parts: e.g., major, minor, patch-level, build number, RC number.</dd>

  <dt id="externalreleasenumber">External Release Number</dt>
  <dd>External release numbers are the numbers that users see.  Often,
  they will be the same as the internal release number.
  That is especially true if the product being built is a component
  intended to be reused by another engineering group in the same
  development organization.  External release numbers can be different
  for products that face competition.  External release number are
  simpler, and may not count up logically. E.g., a certain major ISP
  jumped up to version 8 of their client software because their
  competition had released version 8.  Later, the competition used
  version "10 Optimized" rather than "10.1" or "11".</dd>

  <dt id="releasenumber">Release Number</dt>
  <dd>The term "release number" by itself refers to an <a
  href="#externalreleasenumber" class="def">external release
  number</a>.  Users normally are not aware of the existence of any
  internal release numbers.</dd>

 </dl>
 </div> <!-- /process_section -->



 <div id="tools_section"> 

 <h3>Development Tool Terms</h3>

 <dl>

  <dt id="vc">Version Control System</dt>
  <dd>DEFINITION1</dd>

  <dt id="logmessage">Commit Log Message</dt>
  <dd>DEFINITION1</dd>

  <dt id="issuetracker">Issue Tracker</dt>
  <dd>DEFINITION1</dd>

  <dt id="unittestauto">Unit Testing Automation</dt>
  <dd>DEFINITION1</dd>

  <dt id="autobuild">Automated Build System</dt>
  <dd>DEFINITION1</dd>

  <dt id="codeanalysis">Source Code Analysis Tool</dt>
  <dd>DEFINITION1</dd>

  <dt id="stylechecker">Style Checker</dt>
  <dd>DEFINITION1</dd>

  <dt id="prettyprinter">Source Code Formatter (Pretty Printer)</dt>
  <dd>DEFINITION1</dd>

  <dt id="systestauto">System Test Automation</dt>
  <dd>DEFINITION1</dd>

 </dl>
 </div> <!-- /tools_section -->



 <div id="requirements_section"> 
 <h3>Requirements Terms</h3>

 <dl>

  <dt id="featurespec">Feature specification</dt>
  
  <dd>A feature specification focuses on one feature of a software
  product and completely describes how that feature can be used.  It
  includes a brief description of the purpose of the feature, the
  input and output, and any constraints.  Individual bullet items give
  precise details on all aspects of the feature.  One feature may be
  used in many different ways as part of many different use cases.</dd>

  <dt id="usecase">Use case</dt>  
  <dd>The main part of a use case is a set of steps that give an
  example of how an <a href="#actor" class="def">actor</a> can use the
  product to succeed at a goal.  These steps are called the "Main
  success scenario", and they include both user intentions and system
  responses.  One use case may show how the actor uses several
  features to accomplish a goal.</dd>

  <dt id="actor">Actor</dt>  
  <dd>A user or an external system that uses the system being built.</dd>
  
 </dl>
 </div> <!-- /requirements_section -->


 <div id="design_section"> 
 <h3>Design Terms</h3>

 <dl>

  <dt id="TERM2">TERM2</dt>
  <dd>DEFINITION2</dd>

 </dl>
 </div> <!-- /design_section -->


 
 <div id="designgoals_section"> 
 <h3>Design Goals</h3>

 <dl>

  <dt id="dg_correctness">Correctness</dt>
  <dd>This design correctly matches the given requirements.</dd>

  <dt id="dg_feasibility">Feasibility</dt>
  <dd>This design can be implemented and tested with the planned
  amount of time and effort.</dd>

  <dt id="dg_understandability">Understandability</dt> 
  <dd>Developers can understand this design and correctly implement
  it. </dd>

  <dt id="dg_guidance">Implementation phase guidance</dt> 
  <dd>This design divides the implementation into components or
  aspects that can correspond to reasonable implementation tasks.</dd>

  <dt id="dg_modularity">Modularity</dt>
  <dd>Concerns are clearly separated so that the impact of most design
  changes would be limited to only one or a few modules.</dd>

  <dt id="dg_extensibility">Extensibility</dt>
  <dd>New features or components can be easily added later.</dd>

  <dt id="dg_testability">Testability</dt>
  <dd> It is easy to test components of this design independently, and
  information is available to help diagnose defects.</dd>

  <dt id="dg_efficency">Efficiency</dt> 
  <dd>The design enables the system to perform functions with an
  acceptable amount of time, storage space, bandwidth, and other
  resources.</dd>

  <dt id="dg_easy_integration">Ease of integration</dt>
  <dd>The components will work together.</dd>

  <dt id="dg_cap_match">Capacity matching</dt>
  <dd>The architecture deploys components onto machines that provide
  needed resources with reasonable total expense.</dd>

  <dt id="dg_expressiveness">Expressiveness</dt>
  <dd>It allows for storage of all valid values and
    relationships</dd>

  <dt id="dg_easy_access">Ease of access</dt>
  <dd>Application code to access stored data is simple</dd>

  <dt id="dg_data_reliability">Reliability</dt>
  <dd>Stored data cannot easily be corrupted by
    defective code, concurrent access, or unexpected process
    termination</dd>

  <dt id="dg_data_capacity">Data capacity</dt>
  <dd>The system can store the amount of data needed.</dd>

  <dt id="dg_data_security">Data security</dt>
  <dd>Protection of sensitive user and corporate data from
    unauthorized access or modification</dd>

  <dt id="dg_data_performance">Performance</dt>
  <dd>Data can be accessed quickly</dd>

  <dt id="dg_data_interop">Interoperability</dt>
  <dd>The database or data files can be accessed and updated by
    other applications</dd>

  <dt id="dg_no_intrusion">Intrusion prevention</dt>
  <dd>Prevent, e.g., hackers opening a command shell on our
  server.</dd>

  <dt id="dg_no_abuse">Abuse prevention</dt>
  <dd>Prevention of abuse (e.g., using our system to send spam).</dd>

  <dt id="dg_auditability">Auditability</dt>
  <dd>All changes can be accounted for later.</dd>

  <dt id="dg_use_understand">Understandability and learnability</dt>
  <dd>Users can reasonably be
    expected to understand the UI at first sight.  Users will be able
    to discover additional features without aid from other users or
    documentation, and they will be able to recall what they have
    learned.</dd>

  <dt id="dg_use_efficiency">Task support and efficiency</dt>
  <dd>The UI is well matched to the
    users' tasks and it can be used with a reasonable number of clicks
    and keystrokes.</dd>

  <dt id="dg_use_safety">Safety</dt>
  <dd>Users are not likely to accidentally produce an
    undesired result (e.g., delete data, or send a half-finished
    email).</dd>

  <dt id="dg_use_consistency">Consistency and familiarity</dt>
  <dd>Users can apply their knowledge
    of similar UIs or UI standards to this system.</dd>
 </dl>
 </div> <!-- /designgoals_section -->



 <div id="qa_section">
 <h3>QA Terms</h3>

 <dl>

  <dt id="bug">Bug</dt>

  <dd><i>n.</i> <b>Deprecated</b> since 1991. See <a
  href="#defect">defect</a>.</dd>


  <dt id="error">Error</dt>
  
  <dd><i>v.</i> A mistaken thought in the developer's mind.  Often
  caused by miscommunication or bad assumptions.  Errors can create <a
  href="#defect">defects</a>.  E.g., a developer might erroneously
  think that the square root of -4 is -2.</dd>

  
  <dt id="defect">Defect</dt>

  <dd><i>n.</i> The result of the developer's <a
  href="#error">error</a> embodied in the product source code, initial
  data, or documents.  E.g., a square root function which allows
  negative numbers as arguments is defective.  Defects can be removed
  by changing the source code, initial data, or document.</dd>


  <dt id="fault">Fault</dt>

  <dd><i>n.</i> The execution of defective code.  E.g., if a certain
  input is provided to defective code, it may cause an exception, or
  go into an infinite loop, or store an incorrect value in an internal
  variable.  A fault is not normally visible to users, only the <a
  href="#failure">failure</a> is visible.</dd>


  <dt id="failure">Failure</dt>

  <dd><i>n.</i> The user-visible result of a <a
  href="#fault">fault</a>. E.g., an error message or an incorrect
  result.  This is evidence that can be reported in a defect report.
  Developers use failure evidence during debugging to eventually find
  and remove <a href="#defect">defects</a>.</dd>

 </dl>
 </div> <!-- /qa_section -->


 <div id="qagoals_section"> 
 <h3>QA Goals</h3>

 <dl>

   <dt id="qg_Func_Correctness">Functionality &gt; Correctness</dt>

   <dd>Correctness is the most basic quality goal.  It means that,
   when valid inputs are given and the system is in a valid state and
   under reasonable load, the system's behavior and results will be
   correct.</dd>

   <dt id="qg_Func_Robustness">Functionality &gt; Robustness</dt>

   <dd>Robustness is the system's ability to gracefully handle invalid
   inputs.  It should never be possible for any user input to crash
   the system or corrupt data, even if that user input is abnormal,
   unexpected, or malicious.</dd>

   <dt id="qg_Func_Accuracy">Functionality &gt; Accuracy</dt>

   <dd>Accuracy refers to the mathematical precision of calculations
   done by the system.  Any system that does numeric calculations must
   consider accuracy, e.g., financial or scientific applications.</dd>

   <dt id="qg_Func_Compatibility">Functionality &gt; Compatibility</dt>

   <dd>Systems that claim to follow standards or claim compatibility
   with existing systems must adhere to the relevant file formats,
   protocols, and APIs.  The relevant standards are linked at the top
   of this document.</dd>

   <dt id="qg_Func_Factual">Functionality &gt; Factual correctness</dt>

   <dd>Is the data in the system a true representation of the real
   world?  Any system that contains initial data or gathers data about
   the real world should be sure that the data is factually correct.
   E.g., a tax preparation program should embody correct and
   up-to-date facts about tax law.</dd>

   <dt id="qg_Use_Understand">Usability &gt; Understandability and Readability</dt>

   <dd>Users need to understand the system to use it.  The basic
   metaphor should be understandable and appropriate to user tasks.
   Some defects in understandability include unclear metaphors, poor
   or hard-to-see labels, lack of feedback to confirm the effects of
   user actions, and missing or inadequate on-line help.</dd>

   <dt id="qg_Use_Learnability">Usability &gt; Learnability and Memorability</dt>

   <dd>Every user interface contains some details that users will need
   to learn and remember.  E.g., Alt-F to open the "File" menu.  UI
   cues and rules can make these details easier to learn and remember.
   E.g., the "F" is underlined and, as a rule, the first letter is
   usually the accelerator key.</dd>

   <dt id="qg_Use_Task">Usability &gt; Task support</dt>

   <dd>This is the quality of match between user tasks and the
   system's UI.  Task support defects are cases where the system
   forces the user to take unnatural steps to accomplish a task or
   where the user is given no support for a difficult step in a task.
   E.g., must the user invent an 8-character filename for their
   "Christmas card list"? E.g., must users total their own tax
   deductions?</dd>

   <dt id="qg_Use_Efficiency">Usability &gt; Efficiency</dt>

   <dd>Users should be able to accomplish common tasks with reasonable
   effort.  Common tasks should be possible with only one or two
   steps.  The difficulty of each step should also be considered.
   E.g., does the user have to remember a long code number or click on
   a very small button?</dd>

   <dt id="qg_Use_Safety">Usability &gt; Safety</dt>

   <dd>Humans are error-prone, but the negative effects of common
   errors should be limited.  E.g., users should realize that a given
   command will delete data, and be asked to confirm their intent or
   have the option to undo.</dd>

   <dt id="qg_Use_Consistency">Usability &gt; Consistency and Familiarity</dt>

   <dd>Users should be able to apply their past
   experience from other similar systems.  This means
   that user interface standards should be followed, and common
   conventions should be used whenever possible.  Also, UI elements
   that appear in several parts of the UI should be used consistently,
   unless another UI quality takes priority.  E.g., if most currency
   entry fields do not require a dollar-sign, then one that does
   demand it is a consistency defect, unless there is a real chance
   that the user is dealing with another currency on that step in
   his/her task.
   </dd>

   <dt id="qg_Use_Subjective">Usability &gt; Subjective satisfaction</dt>

   <dd>Users should feel generally satisfied with the UI.  This is a
   subjective quality that sums up the other user interface qualities
   as well as aesthetics.</dd>

   <dt id="qg_Security">Security</dt>

   <dd>The system should allow usage only by authorized users, and
   restrict usage based on permissions.  The system
   should not allow users to side-step security rule or exploit
   security holes.  E.g., all user input should be validated and any
   malicious input should be rejected.</dd>

   <dt id="qg_Rely_ConsistLoad">Reliability &gt; Consistency under load</dt>

   <dd>Every system has some capacity limits.  What happens when those
   limits are exceeded? The system should never lose or corrupt
   data.</dd>

   <dt id="qg_Rely_ConsistConcur">Reliability &gt; Consistency under concurrency</dt>

   <dd>Systems that allow concurrent access by multiple users, or that
   use concurrency internally, should be free of race conditions and
   deadlock.</dd>

   <dt id="qg_Rely_AvailLoad">Reliability &gt; Availability under load</dt>

   <dd>Every system has some capacity limits.  What happens when those
   limits are exceeded? The system should continue to service those
   requests that it is capable of handling.  It should not crash or
   stop processing all requests.</dd>

   <dt id="qg_Rely_Longevity">Reliability &gt; Longevity</dt>

   <dd>The system should continue to operate as long as it is needed.
   It should not gradually use up a limited resource.  Example
   longevity defects include memory leaks or filling the disk with log
   files.</dd>

   <dt id="qg_Efficiency">Efficiency</dt>

   <dd>The system's operations should execute quickly, with reasonable
   use of machine and network resources.  E.g., if one user does one
   operation, it should execute efficiently.</dd>

   <dt id="qg_Scalability">Scalability</dt>

   <dd>Scalability is a general quality that holds when the system
   continues to satisfy its requirements when various usage parameters
   are increased.  E.g., a file server might be scalable to a high
   number of users, or to very large files or very high capacity
   disks.  Several specific scalability goals are listed below.</dd>

   <dt id="qg_Scalability_PerformLoad">Scalability &gt; Performance under load</dt>

   <dd>This is a specific type of scalability goal dealing with the
   performance of the system at times when it is servicing many
   requests from many users.</dd>


   <dt id="qg_Scalability_Volume">Scalability &gt; Large data volume</dt>

   <dd>This is a specific type of scalability goal dealing with the
   ability for the system to handle large data sets.  Operations
   should continue to be correct and efficient as data set size
   increases.  Furthermore, the user interface should still be usable
   as the data presented to users increases in length.</dd>

   <dt id="qg_Operability">Operability</dt>

   <dd>The long-term needs of system administrators should be reliably
   supported.  E.g., is the system easy to install? Can the
   administrator recover from a crash?  Is there sufficient log output
   to diagnose problems in the field?  Can the system's data be backed
   up without downtime? Can the system be upgraded practically?</dd>

   <dt id="qg_Maintainability_Understand">Maintainability &gt; Understandability</dt>

   <dd>Will it be easy for (future) developers to understand how the system
   works?</dd>

   <dt id="qg_Maintainability_Evolvability">Maintainability &gt; Evolvability</dt>

   <dd>Can the system easily be modified and extended over time?</dd>

   <dt id="qg_Maintainability_Testability">Maintainability &gt; Testability</dt>

   <dd>Can the system easily be tested?  Do the requirements precisely
   specify possible inputs and the desired results?  Can the system be
   tested in parts?  When failures are observed, can they be traced
   back to defects in specific components (i.e., debugging)?  Is
   testing practical with the available testing tools?</dd>

 </dl>
 </div> <!-- /qagoals_section -->


 <div id="additional_section">
 <h3>Additional Standard Terms</h3>
 
 <p>For additional standard terms, see the following reference sites:</p>
 <ul>
  <li><a href="http://www.dictionary.com/">Dictionary.com</a></li>
  <li><a href="http://www.whatis.com/">Whatis.com</a></li>
  <li><a href="http://www.nist.gov/dads/">NIST Dictionary of Algorithms and Data Structures</a></li>
  <li><a href="http:/http://foldoc.doc.ic.ac.uk/foldoc/index.html">Free on-line dictionary of computing</a></li>
  <li><a href="http://www-3.ibm.com/ibm/terminology/goc/gocmain.htm">IBM's glossary of computing terms</a></li>
  <li><a href="http://www.jargon.org/">Jargon File</a></li>
 </ul>
 </div> <!-- /addtional_section -->


</div>

<div class="legal1">Company Proprietary</div>

<div class="footnote">
 Copyright &#169; 2003-2004 Jason Robbins.  All rights reserved. <a href="readyset-license.html">License terms</a>.
 Retain this copyright statement whenever this file is used as a
 template.
</div>

</div>
</body>
</html>
